Toliau nei pyptelėjimas: incidentų valdymo įvaldymas naudojant įspėjimo sistemų automatizavimą

Tai scenarijus, pažįstamas technikos specialistams visame pasaulyje: ausį rėžiantis įspėjimo garsas nakties tamsoje. Tai skaitmeninė sirena, kuri ištraukia jus iš miego ir reikalauja nedelsiant atkreipti dėmesį. Daugelį metų pagrindinė įspėjimo sistemos funkcija buvo būtent tai – įspėti. Tai buvo sudėtingas peidžeris, profesionaliai sukurtas rasti tinkamą žmogų problemai išspręsti. Tačiau šiandieninėse sudėtingose, paskirstytose ir pasaulinio masto sistemose vien tik pažadinti ką nors nebepakanka. Rankinio įsikišimo kaina, matuojama prastovomis, pajamų praradimu ir žmogaus perdegimu, yra per didelė.

Šiuolaikiniai įspėjimai patobulėjo. Tai nebėra tik pranešimų sistema; tai centrinė nervų sistema, skirta automatizuotam incidentų valdymui. Tai paleidimo taškas intelektualių veiksmų kaskadai, skirtai diagnozuoti, pašalinti ir išspręsti problemas, kol žmogui netenka įsikišti. Šis vadovas skirtas patikimumo inžinieriams (SRE), DevOps profesionalams, IT operacijų komandoms ir inžinerijos vadovams, kurie yra pasirengę žengti toliau nei pyptelėjimas. Išnagrinėsime principus, praktiką ir įrankius, reikalingus transformuoti jūsų įspėjimo strategiją nuo reaktyvaus pranešimų modelio iki aktyvaus, automatizuoto sprendimų variklio.

Įspėjimo raida: nuo paprastų pingų iki intelektualaus orkestravimo

Norint suprasti, kur einame, būtina suprasti, kur buvome. Įspėjimo sistemų kelionė atspindi didėjantį mūsų programinės įrangos architektūrų sudėtingumą.

1 fazė: rankinė era – „Kažkas sugedo!“

Ankstyvaisiais IT laikais stebėjimas buvo primityvus. Scenarijus galėtų patikrinti, ar serverio procesoriaus naudojimas viršijo 90% ribą, ir, jei taip, išsiųsti el. laišką į platinimo sąrašą. Nebuvo budėjimo planavimo, eskalavimo ar konteksto. Įspėjimas buvo paprastas, dažnai paslaptingas, fakto konstatavimas. Atsakas buvo visiškai rankinis: prisijungti, ištirti ir pataisyti. Šis požiūris lėmė ilgą sprendimo laiką (MTTR – vidutinis laikas iki sprendimo) ir reikalavo gilių sistemos žinių iš kiekvieno operatoriaus.

2 fazė: pranešimų era – „Pabusk, žmogau!“

Specializuotų įspėjimo platformų, tokių kaip PagerDuty, Opsgenie (dabar Jira Service Management) ir VictorOps (dabar Splunk On-Call), atsiradimas žymėjo reikšmingą šuolį į priekį. Šie įrankiai profesionaliai įformino pranešimo aktą. Jie pristatė svarbias sąvokas, kurios dabar yra pramonės standartas:

• Budėjimo tvarkaraščiai: užtikrinti, kad tinkamas asmuo būtų informuotas tinkamu laiku bet kurioje pasaulio vietoje.
• Eskalavimo politika: jei pagrindinis budintis inžinierius nepatvirtina įspėjimo, jis automatiškai perkeliamas antriniam kontaktui arba vadovui.
• Daugiakanaliai pranešimai: pasiekti inžinierius naudojant tiesioginius pranešimus, SMS, telefono skambučius ir pokalbių programas, kad įspėjimas būtų pastebėtas.

Ši era buvo skirta vidutinio patvirtinimo laiko (MTTA) mažinimui. Pagrindinis dėmesys buvo skiriamas patikimam ir greitam žmogaus įtraukimui į problemą. Nors tai buvo didžiulis patobulinimas, visa diagnozavimo ir taisymo našta vis dar teko budinčiam inžinieriui, o tai lėmė įspėjimų nuovargį ir perdegimą.

3 fazė: automatizavimo era – „Leiskite sistemai tai sutvarkyti“.

Tai dabartinė ir būsima įspėjimo būsena. Įspėjimas nebėra mašinos atsakomybės pabaiga; tai pradžia. Šioje paradigmoje įspėjimas yra įvykis, kuris suaktyvina iš anksto apibrėžtą, automatizuotą darbo eigą. Tikslas yra sumažinti arba pašalinti žmogaus įsikišimo poreikį vis didesnei įprastų incidentų klasei. Šis požiūris tiesiogiai siekia sumažinti vidutinį sprendimo laiką (MTTR), suteikiant sistemai galią pačiai pasitaisyti. Jis traktuoja incidentų valdymą ne kaip rankų darbo meną, o kaip inžinerinę problemą, kurią reikia išspręsti naudojant kodą, automatizavimą ir intelektualias sistemas.

Pagrindiniai incidentų valdymo automatizavimo principai

Norint sukurti patikimą automatizavimo strategiją, reikia pakeisti mąstyseną. Tai nereiškia aklai priskirti scenarijus įspėjimams. Tai principingas požiūris į patikimos, patikimos ir keičiamo dydžio sistemos kūrimą.

1 principas: tik veiksmingi įspėjimai

Prieš automatizuodami atsakymą, turite užtikrinti, kad signalas būtų prasmingas. Didžiausia budinčių komandų rykštė yra įspėjimų nuovargis – desensibilizacijos būsena, kurią sukelia nuolatinis mažos vertės, neveiksmingų įspėjimų srautas. Jei įspėjimas paleidžiamas, o teisingas atsakymas yra jį ignoruoti, tai nėra įspėjimas; tai triukšmas.

Kiekvienas jūsų sistemos įspėjimas turi atitikti „TAI KAS?“ testą. Kai įspėjimas paleidžiamas, kokių konkrečių veiksmų reikia imtis? Jei atsakymas yra neaiškus arba „Man reikia tirti 20 minučių, kad sužinočiau“, įspėjimą reikia patikslinti. Didelis procesoriaus naudojimo įspėjimas dažnai yra triukšmas. „Vartotojui skirtas P99 delsos laikas 5 minutes viršijo savo paslaugų lygio tikslą (SLO)“ įspėjimas yra aiškus signalas apie poveikį vartotojui ir reikalauja veiksmų.

2 principas: Runbook kaip kodas

Dešimtmečius runbook buvo statiniai dokumentai – tekstiniai failai arba wiki puslapiai, kuriuose išsamiai aprašomi veiksmai problemai išspręsti. Jie dažnai būdavo pasenę, dviprasmiški ir linkę į žmogaus klaidas, ypač esant gedimo spaudimui. Šiuolaikinis požiūris yra Runbook kaip kodas. Jūsų incidentų valdymo procedūros turėtų būti apibrėžtos vykdomais scenarijais ir konfigūracijos failais, saugomais versijų valdymo sistemoje, tokioje kaip Git.

Šis požiūris suteikia didžiulės naudos:

• Nuoseklumas: taisymo procesas vykdomas identiškai kiekvieną kartą, neatsižvelgiant į tai, kas budi arba koks jų patirties lygis. Tai labai svarbu pasaulinėms komandoms, dirbančioms skirtinguose regionuose.
• Patikrinamumas: galite rašyti testus savo automatizavimo scenarijams, patvirtindami juos parengiamose aplinkose prieš diegdami juos į gamybą.
• Peer Review: atsako procedūrų pakeitimai atliekami per tą patį kodo peržiūros procesą kaip ir programos kodas, gerinant kokybę ir dalijantis žiniomis.
• Audituojamumas: turite aiškią, versijuotą kiekvieno jūsų incidentų valdymo logikos pakeitimo istoriją.

3 principas: pakopinis automatizavimas ir žmogus kilpoje

Automatizavimas nėra viskas arba nieko jungiklis. Palaipsniui, pakopinis požiūris ugdo pasitikėjimą ir sumažina riziką.

• 1 pakopa: diagnostikos automatizavimas. Tai saugiausia ir vertingiausia vieta pradėti. Kai įspėjimas paleidžiamas, pirmasis automatinis veiksmas yra informacijos rinkimas. Tai gali būti žurnalų gavimas iš paveiktos paslaugos, `kubectl describe pod` komandos vykdymas, duomenų bazės užklausa dėl ryšio statistikos arba metrikų gavimas iš konkretaus informacijos suvestinės. Tada ši informacija automatiškai pridedama prie įspėjimo arba incidento bilieto. Vien tai gali sutaupyti budinčiam inžinieriui 5–10 minučių karštligiško informacijos rinkimo kiekvieno incidento pradžioje.
• 2 pakopa: siūlomi taisymo būdai. Kitas žingsnis yra pateikti budinčiam inžinieriui iš anksto patvirtintą veiksmą. Vietoj to, kad sistema imtųsi veiksmų pati, ji pateikia mygtuką įspėjime (pvz., Slack arba įspėjimo įrankio programėlėje), kuriame rašoma „Iš naujo paleisti paslaugą“ arba „Avariškai perjungti duomenų bazę“. Žmogus vis dar yra galutinis sprendimų priėmėjas, tačiau pats veiksmas yra vieno paspaudimo, automatizuotas procesas.
• 3 pakopa: visiškai automatizuotas taisymas. Tai yra paskutinė pakopa, skirta gerai suprantamiems, mažos rizikos ir dažniems incidentams. Klasikinis pavyzdys yra bestatė žiniatinklio serverio kapsulė, kuri tapo nereaguojanti. Jei kapsulės iš naujo paleidimas turi didelę sėkmės tikimybę ir mažą neigiamo šalutinio poveikio riziką, šis veiksmas gali būti visiškai automatizuotas. Sistema aptinka gedimą, vykdo paleidimą iš naujo, patikrina, ar paslauga veikia, ir išsprendžia įspėjimą, galbūt niekada nepažadinus žmogaus.

4 principas: turtingas kontekstas yra karalius

Automatizuota sistema priklauso nuo aukštos kokybės duomenų. Įspėjimas niekada neturėtų būti tik viena teksto eilutė. Tai turi būti turtinga, kontekstinė informacijos naudingoji našta, kurią gali naudoti ir žmonės, ir mašinos. Geras įspėjimas turėtų apimti:

• Aiški santrauka apie tai, kas sugedo ir koks poveikis vartotojui.
• Tiesioginės nuorodos į atitinkamas stebėjimo informacijos suvestines (pvz., Grafana, Datadog) su jau pritaikytu teisingu laiko intervalu ir filtrais.
• Nuoroda į žaidimų knygą arba runbook, skirtą šiam konkrečiam įspėjimui.
• Pagrindiniai metaduomenys, tokie kaip paveikta paslauga, regionas, klasteris ir naujausia diegimo informacija.
• Diagnostiniai duomenys, surinkti naudojant 1 pakopos automatizavimą.

Šis turtingas kontekstas labai sumažina inžinieriaus pažinimo krūvį ir suteikia reikiamus parametrus, kad automatizuoti taisymo scenarijai veiktų teisingai ir saugiai.

Automatizuoto incidentų valdymo kanalo kūrimas: praktinis vadovas

Perėjimas prie automatizuoto modelio yra kelionė. Štai žingsnis po žingsnio sistema, kurią galima pritaikyti bet kuriai organizacijai, neatsižvelgiant į jos dydį ar vietą.

1 žingsnis: pagrindinis stebėjimas

Negalite automatizuoti to, ko nematote. Patikima stebėjimo praktika yra nepakeičiama sąlyga bet kokiam prasmingam automatizavimui. Ji grindžiama trimis stebėjimo ramsčiais:

• Metrika: laiko eilučių skaitiniai duomenys, kurie parodo, kas vyksta (pvz., užklausų dažnis, klaidų procentas, procesoriaus panaudojimas). Čia dažnai naudojami tokie įrankiai kaip Prometheus ir valdomos paslaugos iš tokių teikėjų kaip Datadog arba New Relic.
• Žurnalai: laiko žymomis pažymėti atskirų įvykių įrašai. Jie parodo, kodėl kažkas įvyko. Centralizuotos žurnalo platformos, tokios kaip ELK Stack (Elasticsearch, Logstash, Kibana) arba Splunk, yra būtinos.
• Pėdsakai: išsamūs užklausos kelionės per paskirstytą sistemą įrašai. Jie yra neįkainojami nustatant mikroservisų architektūrų kliūtis ir gedimus. OpenTelemetry yra besiformuojantis pasaulinis standartas, skirtas instrumentuoti jūsų programas pėdsakams.

Be aukštos kokybės signalų iš šių šaltinių, jūsų įspėjimai bus nepatikimi, o jūsų automatizavimas skris aklai.

2 žingsnis: įspėjimo platformos pasirinkimas ir konfigūravimas

Jūsų centrinė įspėjimo platforma yra jūsų operacijos smegenys. Vertindami įrankius, žiūrėkite toliau nei pagrindinis planavimas ir pranešimai. Pagrindinės automatizavimo funkcijos yra:

• Turtinga integracija: kaip gerai ji integruojama su jūsų stebėjimo įrankiais, pokalbių programomis (Slack, Microsoft Teams) ir bilietų sistemomis (Jira, ServiceNow)?
• Galingas API ir Webhooks: jums reikia programinės kontrolės. Galimybė siųsti ir gauti webhooks yra pagrindinis mechanizmas išoriniam automatizavimui suaktyvinti.
• Integruotos automatizavimo galimybės: šiuolaikinės platformos tiesiogiai prideda automatizavimo funkcijas. PagerDuty automatizavimo veiksmai ir Rundeck integracija arba Jira Service Management (Opsgenie) veiksmo kanalai leidžia suaktyvinti scenarijus ir runbook tiesiogiai iš paties įspėjimo.

3 žingsnis: automatizavimo kandidatų nustatymas

Nemėginkite automatizuoti visko iš karto. Pradėkite nuo žemiausiai kabančių vaisių. Jūsų incidentų istorija yra aukso kasykla duomenų, skirtų nustatyti gerus kandidatus. Ieškokite incidentų, kurie yra:

• Dažni: automatizuoti ką nors, kas vyksta kiekvieną dieną, suteikia daug didesnę investicijų grąžą nei automatizuoti retą įvykį.
• Gerai suprantami: pagrindinė priežastis ir taisymo veiksmai turėtų būti žinomi ir dokumentuoti. Venkite automatizuoti atsakymus į paslaptingus ar sudėtingus gedimus.
• Maža rizika: taisymo veiksmas turėtų turėti minimalų sprogimo spindulį. Iš naujo paleisti vieną, bestatę kapsulę yra maža rizika. Numesti gamybos duomenų bazės lentelę nėra.

Paprasta jūsų incidentų valdymo sistemos užklausa dėl dažniausiai pasitaikančių įspėjimų pavadinimų dažnai yra geriausia vieta pradėti. Jei „Diskas pilnas serveryje X“ pasirodo 50 kartų per pastarąjį mėnesį, o sprendimas visada yra „Vykdyti valymo scenarijų“, radote savo pirmąjį kandidatą.

4 žingsnis: pirmojo automatizuoto runbook įgyvendinimas

Pažvelkime į konkretų pavyzdį: žiniatinklio programos kapsulė Kubernetes klasteryje neišlaiko savo sveikatos patikrinimo.

1. Paleidiklis: Prometheus Alertmanager taisyklė nustato, kad paslaugos `up` metrika buvo 0 ilgiau nei dvi minutes. Ji paleidžia įspėjimą.
2. Maršrutas: įspėjimas siunčiamas į jūsų centrinę įspėjimo platformą (pvz., PagerDuty).
3. Veiksmas – 1 pakopa (diagnostika): PagerDuty gauna įspėjimą. Per webhook ji suaktyvina AWS Lambda funkciją (arba scenarijų be serverio platformoje pagal jūsų pasirinkimą). Ši funkcija:
   • Išanalizuoja įspėjimo naudingąją apkrovą, kad gautų kapsulės pavadinimą ir vardų sritį.
   • Vykdo `kubectl get pod` ir `kubectl describe pod` prieš atitinkamą klasterį, kad gautų kapsulės būseną ir naujausius įvykius.
   • Gauna paskutines 100 žurnalų eilučių iš nepavykusios kapsulės naudodama `kubectl logs`.
   • Prideda visą šią informaciją kaip turtingą pastabą atgal į PagerDuty incidentą per savo API.
4. Sprendimas: Šiuo metu galite pasirinkti pranešti budinčiam inžinieriui, kuris dabar turi visus diagnostinius duomenis, reikalingus greitam sprendimui priimti. Arba galite pereiti prie visiško automatizavimo.
5. Veiksmas – 3 pakopa (taisymas): Lambda funkcija tęsia vykdymą `kubectl delete pod <pod-name>`. Kubernetes' ReplicaSet valdiklis automatiškai sukurs naują, sveiką kapsulę, kad ją pakeistų.
6. Patikrinimas: Tada scenarijus įeina į ciklą. Jis laukia 10 sekundžių, tada patikrina, ar nauja kapsulė veikia ir ar išlaikė savo pasirengimo zondą. Jei sėkmingai po minutės, scenarijus vėl iškviečia PagerDuty API, kad automatiškai išspręstų incidentą. Jei problema išlieka po kelių bandymų, ji pasiduoda ir nedelsiant perkelia incidentą žmogui, užtikrindama, kad automatizavimas neįstrigtų gedimo cikle.

5 žingsnis: automatizavimo mastelio keitimas ir brandinimas

Jūsų pirmoji sėkmė yra pagrindas, ant kurio galima statyti. Jūsų praktikos brandinimas apima:

• Runbook saugyklos kūrimas: centralizuokite savo automatizavimo scenarijus specialioje Git saugykloje. Tai tampa bendra, pakartotinai naudojama biblioteka visai jūsų organizacijai.
• AIOps įvedimas: augant galite pasinaudoti dirbtiniu intelektu IT operacijoms (AIOps) įrankiais. Šios platformos gali susieti susijusius įspėjimus iš skirtingų šaltinių į vieną incidentą, sumažindamos triukšmą ir padėdamos automatiškai nustatyti pagrindinę priežastį.
• Automatizavimo kultūros kūrimas: automatizavimas turėtų būti aukščiausios klasės pilietis jūsų inžinerijos kultūroje. Švęskite automatizavimo laimėjimus. Skirkite laiko sprintų metu, kad inžinieriai automatizuotų savo veiklos skausmo taškus. Pagrindinė komandos sveikatos metrika gali būti „bemiegių naktų skaičius“, siekiant sumažinti ją iki nulio naudojant patikimą automatizavimą.

Žmogiškasis elementas automatizuotame pasaulyje

Dažna baimė yra ta, kad automatizavimas padarys inžinierius pasenusiais. Realybė yra priešinga: ji pakelia jų vaidmenį.

Vaidmenų keitimas: nuo ugniagesio iki gaisrų prevencijos inžinieriaus

Automatizavimas išlaisvina inžinierius nuo pasikartojančių, rankinių ugniagesių darbo. Tai leidžia jiems sutelkti dėmesį į didesnės vertės, patrauklesnį darbą: architektūrinius patobulinimus, našumo inžineriją, sistemos atsparumo didinimą ir naujos kartos automatizavimo įrankių kūrimą. Jų darbas pasikeičia nuo reagavimo į gedimus iki sistemos, kurioje gedimai automatiškai tvarkomi arba visiškai užkertami keliai, kūrimo.

Pomirtinių apžiūrų ir nuolatinio tobulinimo svarba

Kiekvienas incidentas, nesvarbu, ar jį išsprendė žmogus, ar mašina, yra mokymosi galimybė. Nekaltas pomirtinis procesas yra svarbesnis nei bet kada. Pokalbio dėmesys turėtų apimti tokius klausimus kaip:

• Ar mūsų automatizuota diagnostika pateikė teisingą informaciją?
• Ar šis incidentas galėjo būti ištaisytas automatiškai? Jei taip, koks yra veiksmas, skirtas sukurti tą automatizavimą?
• Jei automatizavimas buvo bandomas ir nepavyko, kodėl jis nepavyko ir kaip galime padaryti jį patikimesnį?

Pasitikėjimo sistema kūrimas

Inžinieriai per naktį miegos tik tuo atveju, jei pasitikės automatizavimu, kad jis darys tai, kas teisinga. Pasitikėjimas kuriamas per skaidrumą, patikimumą ir kontrolę. Tai reiškia, kad kiekvienas automatizuotas veiksmas turi būti kruopščiai registruojamas. Turėtų būti lengva pamatyti, kuris scenarijus buvo paleistas, kada jis buvo paleistas ir kokie buvo jo rezultatai. Pradėjus nuo diagnostikos ir siūlomų automatizavimų prieš pereinant prie visiškai autonominių veiksmų, komanda laikui bėgant gali įgyti pasitikėjimo sistema.

Pasaulinės incidentų valdymo automatizavimo aplinkybės

Tarptautinėms organizacijoms į automatizavimą orientuotas požiūris suteikia unikalių pranašumų.

Perdavimai pagal saulę

Automatizuoti runbook ir turtingas kontekstas leidžia sklandžiai perduoti budinčius inžinierius skirtingose laiko juostose. Inžinierius Šiaurės Amerikoje gali pradėti savo dieną peržiūrėdamas incidentų žurnalą, kurie buvo automatiškai išspręsti per naktį, kai jų kolegos Azijos ir Ramiojo vandenyno regione budėjo. Kontekstą užfiksuoja sistema, o ne prarandamas skubotame perdavimo susitikime.

Standartizavimas visuose regionuose

Automatizavimas užtikrina nuoseklumą. Kritinis incidentas yra tvarkomas visiškai taip pat, nesvarbu, ar sistemą valdo komanda Europoje, ar Pietų Amerikoje. Tai pašalina regioninius proceso skirtumus ir užtikrina, kad geriausia praktika būtų taikoma visame pasaulyje, sumažinant riziką ir gerinant patikimumą.

Duomenų saugojimo vieta ir atitiktis

Kuriant automatizavimą, kuris veikia skirtingose teisinėse jurisdikcijose, labai svarbu atsižvelgti į duomenų saugojimo vietą ir privatumo reglamentus (tokius kaip GDPR Europoje, CCPA Kalifornijoje ir kt.). Jūsų automatizavimo scenarijai turi būti sukurti taip, kad atitiktų reikalavimus, užtikrinant, kad diagnostiniai duomenys nebūtų netinkamai perkeliami per sienas ir kad veiksmai būtų registruojami audito tikslais.

Išvada: jūsų kelionė į išmanesnį incidentų valdymą

Raida nuo paprasto įspėjimo iki visiškai automatizuotos incidentų valdymo darbo eigos yra transformuojanti kelionė. Tai poslinkis nuo reaktyvaus ugniagesių darbo kultūros prie aktyvios inžinerijos. Laikydamiesi veiksmų įspėjimo principų, traktuodami runbook kaip kodą ir taikydami pakopinį, pasitikėjimą kuriantį įgyvendinimo požiūrį, galite sukurti atsparesnę, efektyvesnę ir humaniškesnę budėjimo patirtį.

Tikslas nėra pašalinti žmones iš kilpos, o pakelti jų vaidmenį – suteikti jiems galią dirbti su sudėtingiausiomis problemomis automatizuojant kasdienius dalykus. Galutinis jūsų įspėjimo ir automatizavimo sistemos sėkmės matas yra rami naktis. Tai pasitikėjimas, kad jūsų sukurta sistema gali pasirūpinti savimi, leidžiant jūsų komandai sutelkti savo energiją į ateities kūrimą. Jūsų kelionė prasideda šiandien: nustatykite vieną dažną, rankinį uždavinį savo incidentų valdymo procese ir užduokite paprastą klausimą: „Kaip galime tai automatizuoti?“